src/main/java/com/ryu/studyhelper/solvedac/client/SolvedAcClient.java (3)

25-25: 파라미터명 네이밍 컨벤션 위반

ResponseType은 파라미터이므로 lowerCamelCase(responseType)를 사용해야 합니다.

♻️ 수정 제안

-    private <T> T get(String path, Map<String, String> params, Class<T> ResponseType) {
+    private <T> T get(String path, Map<String, String> params, Class<T> responseType) {
         return rest.get()
                 .uri(b -> {
                     var ub = b.path(path);
                     if (params != null) params.forEach(ub::queryParam);
                     return ub.build(); // 인코딩/결합은 RestClient에 맡김
                 })
                 .accept(MediaType.APPLICATION_JSON)
                 .retrieve()
-                .body(ResponseType);
+                .body(responseType);
     }

---

16-21: RestClient를 외부에서 주입받도록 개선 검토

현재 RestClient를 생성자 내부에서 직접 빌드하고 있어 테스트 시 모킹이 어렵습니다. RestClient 또는 RestClient.Builder를 주입받는 방식을 고려해보세요.

♻️ 수정 제안 (선택적)

 `@Component`
 public class SolvedAcClient {
     private final RestClient rest;

-    public SolvedAcClient() {
-        this.rest = RestClient.builder()
+    public SolvedAcClient(RestClient.Builder restClientBuilder) {
+        this.rest = restClientBuilder
                 .baseUrl("https://solved.ac/api/v3")
                 .defaultHeader("User-Agent", "studyhelper/1.0")
                 .build();
     }

---

38-40: getUserInfo와 getUserBio 중복 API 호출

두 메서드 모두 /user/show 엔드포인트를 호출하지만 다른 DTO로 역직렬화합니다. 의도적인 설계라면 괜찮지만, SolvedAcUserResponse에 bio 필드가 이미 포함되어 있다면 하나의 메서드로 통합하는 것이 효율적입니다.

Also applies to: 63-65

src/main/java/com/ryu/studyhelper/problem/service/ProblemService.java (1)

65-77: 주석 처리된 코드 정리 필요

Line 65, 76의 주석 처리된 코드는 불필요하므로 제거하는 것이 좋습니다.

src/main/java/com/ryu/studyhelper/infrastructure/solvedac/client/SolvedAcRestClient.java (2)

16-21: Base URL 하드코딩 및 타임아웃 미설정.

외부 API 호출 시 타임아웃이 설정되지 않으면, solved.ac 서버 응답 지연 시 스레드가 무한 대기할 수 있습니다. 또한 base URL은 application.yml 등 외부 설정으로 관리하는 것이 환경별 유연성에 좋습니다.

♻️ 타임아웃 및 설정 외부화 제안

+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.http.client.SimpleClientHttpRequestFactory;
+
 `@Component`
 public class SolvedAcRestClient {
     private final RestClient rest;
 
-    public SolvedAcRestClient() {
+    public SolvedAcRestClient(`@Value`("${solvedac.api.base-url:https://solved.ac/api/v3}") String baseUrl) {
+        SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
+        factory.setConnectTimeout(5000);
+        factory.setReadTimeout(5000);
         this.rest = RestClient.builder()
-                .baseUrl("https://solved.ac/api/v3")
+                .baseUrl(baseUrl)
+                .requestFactory(factory)
                 .defaultHeader("User-Agent", "studyhelper/1.0")
                 .build();
     }

---

38-65: getUserInfo와 getUserBio가 동일한 엔드포인트(/user/show)를 호출합니다.

두 메서드 모두 /user/show?handle=...을 호출하지만 서로 다른 DTO로 역직렬화합니다. 현재 설계상 의도된 것이라면 괜찮지만, 향후 하나의 호출로 통합하고 상위 레이어에서 필요한 필드를 추출하는 방식도 고려해 보세요.

src/main/java/com/ryu/studyhelper/member/MemberService.java (1)

84-93: getUserInfo 반환값 미사용 — 의도를 명확히 하는 것을 권장합니다.

solvedAcClient.getUserInfo(handle) 호출의 반환값을 사용하지 않고 있습니다. 존재 여부 확인만이 목적이라면 getUserBio 대신 별도의 verifyUserExists(handle) 같은 메서드를 두거나, getUserInfo가 존재 여부 확인용임을 주석이나 네이밍으로 명시하면 가독성이 향상됩니다. 현재 동작에는 문제 없으나, 의도를 더 명확히 표현할 수 있습니다.

src/main/java/com/ryu/studyhelper/infrastructure/solvedac/SolvedAcClient.java (2)

29-39: getUserInfo와 getUserBio의 예외 처리 로직이 동일합니다.

두 메서드의 try-catch 패턴이 동일하므로, 공통 헬퍼 메서드로 추출하면 중복을 줄일 수 있습니다. 현재 규모에서는 큰 문제가 아니므로 향후 메서드 추가 시 고려해도 좋습니다.

♻️ 예시: 공통 예외 처리 헬퍼 추출

+    private <T> T callWithExceptionHandling(String handle, String operation,
+                                             java.util.function.Function<String, T> apiCall) {
+        try {
+            return apiCall.apply(handle);
+        } catch (HttpClientErrorException.NotFound e) {
+            log.info("solved.ac user not found: {}", handle);
+            throw new CustomException(CustomResponseStatus.SOLVED_AC_USER_NOT_FOUND);
+        } catch (Exception e) {
+            log.error("Failed to {} from solved.ac: {}", operation, handle, e);
+            throw new CustomException(CustomResponseStatus.SOLVED_AC_API_ERROR);
+        }
+    }

Also applies to: 100-113

---

49-69: recommendUnsolvedProblems의 catch-all이 CustomException도 잡을 수 있습니다.

현재 solvedAcRestClient가 CustomException을 던지지 않으므로 실질적 문제는 아니지만, 방어적으로 CustomException을 먼저 재throw하면 향후 내부 로직 변경 시 예외가 의도치 않게 SOLVED_AC_API_ERROR로 감싸지는 것을 방지할 수 있습니다.

🛡️ 방어적 예외 처리 제안

         } catch (Exception e) {
+            if (e instanceof CustomException) throw (CustomException) e;
             log.error("Failed to recommend problems for handles: {}", handles, e);
             throw new CustomException(CustomResponseStatus.SOLVED_AC_API_ERROR);
         }

src/main/java/com/ryu/studyhelper/problem/service/ProblemService.java (1)

75-79: System.out.println 사용 — 이번 PR 범위는 아니지만 로거 전환을 권장합니다.

Line 79의 System.out.println은 이번 리팩터링 변경 사항은 아니지만, 클래스에 이미 @Slf4j 등의 로깅 인프라가 있다면 log.info()로 전환하는 것이 운영 환경에서의 관리에 유리합니다. 별도 이슈로 추적하는 것을 고려해 주세요.